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AMENDED BRIEF ON APPEAL 

Mail Stop Appeal Brief - Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir/Madam: 

This Appeal Brief is being filed in response to a Notification of Non-Compliant 
Appeal Brief mailed April 22, 2010, providing a one-month period of reply. As a result, the 
submission of this corrected Appeal Brief is timely filed. The Notification of the Non- 
Compliant Appeal Brief stated that the previous Appeal Brief did not "refer to the 
Specification as originally filed with respect to independent claims 1,18, 20, 24, 25, and 26." 
Accordingly, this Amended Appeal Brief now correctly refers to the original specification by 
page and line number as requested in the Notification of Non-Compliant Appeal Brief. 

The previous Appeal Brief was filed in response to a Notice of Panel Decision 
from Pre-Appeal Brief Review mailed November 10, 2009, rejecting Claims 1, 3, 5-7, 9-11, 
15-20, 24-28, and 30-32. The Notice of Panel Decision from Pre-Appeal Brief Review was 
prepared in response to a Notice of Appeal and Pre-Appeal Brief mailed September 24, 
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2009. Appellant does not believe that a fee is due for this filing. However, if a fee is 
deemed due, authorization is hereby given to charge any deficiency (or credit any balance) 
to the undersigned deposit account 19-0741. 

Accordingly, Appellant respectfully requests reconsideration of the 

Application. 
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REAL PARTY IN INTEREST 

The real party in interest is Spyder Navigations L.L.C., the assignee of 
record, having a place of business at 1209 Orange Street, Wilmington, Delaware 19801 
USA. The assignment to Spyder Navigations L.L.C. was recorded in the records of the 
United States Patent and Trademark Office at Reel/Frame 019660/0286 on August 7, 2007. 
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RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences that will directly affect, be directly 
affected by, or have a bearing on the present appeal, that are known to Appellants or 
Appellants' patent representative. 
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STATUS OF CLAIMS 

The present appeal is directed to Claims 1, 3, 5-7, 9-11, 15-20, 24-28, and 
30-32, all of which stand rejected pursuant to a Final Office Action dated June 24, 2009. 
Claims 1 , 3, 5-7, 9-11,1 5-20, 24-28, and 30-32 are being appealed. Claims 2, 4, 8, 1 2-1 4, 
21-23, and 29 have been canceled. The claims, with appropriate status references, are 
shown in the attached Claims Appendix. 
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STATUS OF AMENDMENTS 

A Final Office Action dated June 24, 2009 was received by Appellants. 
Applicants filed an after final response on August 17, 2009. A Notice of Appeal with a Pre- 
Appeal Brief was electronically filed with the US Patent and Trademark Office on June 1, 
2009. A Notice of Panel Decision from Pre-Appeal Brief Review was mailed September 24, 
2009, in which the rejection of Claims 1, 3, 5-7, 9-11, 15-20, 24-28, and 30-32 was 
maintained. Thus, no amendments have been made in the present Application subsequent 
to the response to the Final Office Action. 
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SUMMARY OF CLAIMED SUBJECT MATTER 

Six independent claims, Claims 18, 20, 24, 25 and 26, are under appeal and 
argued below as a group. 

Claim 1 is directed to a method for streaming media from a streaming server 
111 to a streaming client 101 via a transmission channel. The method includes: 

receiving a first request for media from a streaming client 101 at a streaming 
server 111 (e.g., pg. 9, II. 20-26; pg. 16, II. 19-24); 

sending a response to the received first request from the streaming server 
1 1 1 to the streaming client 1 01 , the response including a plurality of error resilience levels 
supportable by the streaming server in sending the media to the streaming client, wherein 
the plurality of error resilience levels includes a first error resilience level indicating a default 
error resilience level of the streaming server and a second error resilience level indicating an 
alternative error resilience level (e.g., pg. 9, II. 28-29; pg. 13, II. 18-25; pg. 14, II. 5-22; pg. 
16. II. 26-28); 

receiving a second request from the streaming client 101 at the streaming 
server 1 1 1 , the second request including an error resilience level selected from the plurality 
of error resilience levels (e.g., pg. 5, II. 11-17; pg. 10, II. 7-9; pg. 16, II. 30-31); and 

sending the media from the streaming server 1 1 1 to the streaming client 101 
based on the error resilience level (e.g., pg. 10, II. 7-9; pg. 10, In. 26 - pg. 14, In. 30; pg. 17, 
II. 6-15). 

Claim 18 is directed to a client device 101. The client device 101 includes 
receiving means for receiving streaming media sent from a streaming server 1 1 1 to the 
client device 101 via a transmission channel (e.g., 175, pg. 4, II. 19-22; pg. 21, In. 24- pg. 
22, In. 6) and for receiving a plurality of error resilience levels supportable by the streaming 
server 1 1 1 in streaming the media to the client device 101 . The plurality of error resilience 
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levels includes a first error resilience level indicating a default error resilience level of the 
streaming server 111 (e.g., pg. 10, In. 26 - pg. 14, In. 9) and a second error resilience level 
indicating an alternative error resilience level (e.g., pg. 14, II. 9-22; pg. 17, II. 10-15). The 
client device also includes detection means for detecting transmission channel errors (e.g., 
pg. 19, II. 1-3; pg. 21, II. 24-31) and sending means for sending an error resilience selection 
from the received plurality of error resilience levels to the streaming server 1 1 1 (e.g., pg. 19, 
II. 5-6; pg. 21,11. 24-31). 

Claim 20 is directed to a streaming server 111. The streaming server 1 1 1 
includes receiving means for receiving a first request for media from a streaming client 110 
(e.g. network interface 155, pg. 20, II. 26-29) and for receiving a second request from the 
streaming client (e.g. network interface 155, pg. 20, II. 26-29). The second request includes 
an error resilience level selected from a plurality of error resilience levels (e.g., 175, pg. 14, 
II. 5-22; pg. 16, II. 26-28; pg. 21, II. 24-28). The plurality of error resilience levels includes a 
first error resilience level indicating a default error resilience level of the streaming server 
(e.g., pg. 10, In. 26 - pg. 14, In. 9) and a second error resilience level indicating an 
alternative error resilience level (e.g., pg. 14, II. 5-22; pg. 17, II. 10-15). The streaming server 
1 1 1 also includes sending means for sending a response to the first request to the 
streaming client (e.g. network interface 155, pg. 20, II. 26-29). The response includes the 
plurality of error resilience levels supportable by the streaming server in sending the media 
to the streaming client (e.g., pg. 20, In. 16 - pg. 21, In. 6) and for sending streaming media 
to the streaming client via a transmission channel based on the error resilience level (e.g., 
pg. 21, ll. 1-6). 

Claim 24 is directed to a computer-readable medium memory including 
computer-readable instructions program code that, upon execution by a processor, cause a 
device to send a response to a first device requesting media (e.g., program 114, pg. 20, II. 
4-14). The response includes a plurality of error resilience levels supportable when sending 
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the media to the first device (e.g., pg. 9, II. 28-29; pg. 13, II. 18-25; pg. 14, II. 5-22; pg. 16. II. 
26-28). The plurality of error resilience levels includes a first error resilience level indicating 
a default error resilience level of the device (e.g., pg. 10, In. 26 - pg. 14, In. 9) and a second 
error resilience level indicating an alternative error resilience level (e.g., pg. 19, II. 1-3; pg. 
21 , II. 24-31 ). The device further processes a second request received from the first device 
where the second request includes an error resilience level selected from the plurality of 
error resilience levels (e.g., pg. 20, In. 16 - pg. 21, In. 6). The device also sends the media 
to the first device based on the error resilience level (e.g., pg. 21, II. 1-6). 

Claim 25 is directed to a computer-readable medium memory including 
computer-readable instructions program code that, upon execution by a processor, cause 
the processor to receive streamed media from a streaming server via a transmission 
channel, the instructions program code configured to cause a device to send a first request 
for media to a streaming server (e.g., software 174, pg. 21 , II. 30-32) and receive a 
response from the streaming server (e.g., pg. 16, II. 19-24). The response includes a 
plurality of error resilience levels supportable by the streaming server when sending the 
media (e.g., pg. 9, II. 28-29; pg. 13, II. 18-25; pg. 14, II. 5-22; pg. 16. II. 26-28). The plurality 
of error resilience levels includes a first error resilience level indicating a default error 
resilience level of the streaming server (e.g., pg. 10, In. 26 - pg. 14, In. 9) and a second 
error resilience level indicating an alternative error resilience level (e.g., pg. 14, II. 9-22; pg. 
17, II. 10-15). The processor further sends a second request to the streaming server where 
the second request includes an error resilience level selected from the plurality of error 
resilience levels (e.g., pg. 20, In. 16 - pg. 21, In. 6). The processor also receives the media 
from the streaming server based on the error resilience level (e.g., pg. 21, II. 1-6). 

Claim 26 is directed to a method for receiving streamed media from a 
streaming server 111 via a transmission channel. The method includes: 
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sending a first request for media from a streaming client 101 to a streaming 
server 111 (e.g., pg. 9, II. 20-26; pg. 16, II. 19-24); 

receiving a response from the streaming server 1 1 1 at the streaming client 
101 , the response including a plurality of error resilience levels supportable by the streaming 
server 111 when sending the media, wherein the plurality of error resilience levels includes a 
first error resilience level indicating a default error resilience level of the streaming server 
111 and a second error resilience level indicating an alternative error resilience level (e.g., 
pg. 9, II. 28-29; pg. 13, II. 18-25; pg. 14, II. 5-22; pg. 16. II. 26-28); 

sending a second request from the streaming client 101 to the streaming 
server 1 1 1 , the second request including an error resilience level selected from the plurality 
of error resilience levels (e.g., pg. 5, II. 11-17; pg. 10, II. 7-9; pg. 16, II. 30-31); and 

receiving the media from the streaming server at the streaming client based 
on the error resilience level (e.g., pg. 10, II. 7-9; pg. 10, In. 26 - pg. 14, In. 30; pg. 17, II. 6- 
15). 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

One ground of rejection is presented for review in this appeal: The rejection 
of Claims 1 , 3, 5-7, 9-11,1 5-20, 24-28, and 30-32 under 35 U.S.C. § 1 03(a) as being 
unpatentable over U.S. Patent Publication No. 2002/0141740 to Matsui (Matsui) in view of 
U.S. Patent Publication No. 2003/0195979 to Park (Park). 
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ARGUMENT 

I. LEGAL STANDARDS UNDER 35 U.S.C. 103(a) 

35 U.S.C. 103(a) states: 

A patent may not be obtained though the invention is not 
identically disclosed or described as set forth in section 1 02 of 
this title, if the differences between the subject matter sought 
to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art 
to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

Obviousness under 35 U.S.C. 103(a) involves four factual inquiries: (1) the 
scope and content of the prior art; (2) the differences between the claims and the prior art; 
(3) the level of ordinary skill in the pertinent art; and (4) secondary considerations, if any, of 
nonobviousness. See Graham v. John Deere Co., 383 U.S. 1 (1966). 

In proceedings before the Patent and Trademark Office, the Examiner bears 
the burden of establishing a prima facie case of obviousness based upon the prior art. In re 
Piasecki, 745 F.2d 1468, 1471-72 (Fed. Cir. 1984). 

According to M.P.E.P. § 706.02(j), 

35 U.S.C. 103 authorizes a rejection where, to meet the claim, 
it is necessary to modify a single reference or to combine it 
with one or more other references. After indicating that the 
rejection is under 35 U.S.C. 103, the examiner should set forth 
in the Office action: 

(A) the relevant teachings of the prior art relied upon, 
preferably with reference to the relevant column or page 
number(s) and line number(s) where appropriate, 

(B) the difference or differences in the claim over the applied 
reference(s), 

(C) the proposed modification of the applied reference(s) 
necessary to arrive at the claimed subject matter, and 
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(D) an explanation >as to< why >the claimed invention would 
have been obvious to< one of ordinary skill in the art at the 
time the invention was made**. 

** "To support the conclusion that the claimed invention is 
directed to obvious subject matter, either the references must 
expressly or impliedly suggest the claimed invention or the 
examiner must present a convincing line of reasoning as to 
why the artisan would have found the claimed invention to 
have been obvious in light of the teachings of the references." 
Ex parte Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 
1985). 



II. REJECTION OF CLAIMS 1, 3, 5-7, 9-11, 15-20, 24-28, and 30-32 

In section 2 of the final Office Action dated June 24, 2009, Claims 1, 3, 5-7, 
9-11, 15-20, 24-28, and 30-32 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over U.S. Patent Publication No. 2002/0141740 to Matsui (Matsui) in view of 
U.S. Patent Publication No. 2003/0195979 to Park (Park). Appellants respectfully disagree 
because Matsui and Park, alone and in combination, fail to teach, suggest, or disclose all of 
the elements of at least independent Claims 1,18, 20, and 24-26. 



1 . The combination of Matsui and Park fails to show "a default error resilience 
level of the streaming server" as recited by the claims. 

Independent Claims 1,18, 20, and 24-26, recite in part: 

wherein the plurality of error resilience levels includes a 
first error resilience level indicating a default error resilience 
level of the streaming server and a second error resilience 
level indicating an alternative error resilience level; 

(emphasis added.) 

On page 5 of the Office Action, the Examiner states that "Matsui does not 
explicitly disclose a default error resilience level of the streaming server." Appellants agree 
that Matsui fails to teach at least this element of independent Claims 1,18, 20, and 24-26. 
On the continuation sheet of the Advisory Action, the Examiner states: 
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Park discloses "the server 10 provides or informs of at least 
two types of coding formats and the terminal 20 recognizes 
that the corresponding contents can be coded in at least two 
coding formats" (Park [0042]). This shows that there are two 
error resilience levels. Park discloses "The packetizing unit 13 
packetizes the bit streams in a predetermined coding format. 
In the case of MPEG-4, the coding formats are divided into a 
coding format to code one general frame into a whole and a 
coding format using a data partitioning method" (Park [00391). 
This shows that one of the error resilience level is a default 
error resilience level . Therefore, Park discloses the plurality of 
error resilience levels includes a first error resilience level 
indicating a default error resilience level of the streaming 
server and a second error resilience level indicating an 
alternative error resilience level. 

On pages 19-20 of the Final Office Action, the Examiner similarly states: 

In response to Applicants' argument, the examiner 
respectfully disagrees. Park discloses "the server 10 provides 
or informs of at least two types of coding formats and the 
terminal 20 recognizes that the corresponding contents can be 
coded in at least two coding formats" ([0042]), "the server 10 
packetizes and transmits the bit streams in a general coding 
format to the terminal 20" ([0043]), " The packetizing unit 43 
packetizes the bit streams in a predetermined coding format" 
([00491). This shows that there are two different levels from the 
server, where one is a default level . Therefore, Park discloses 
the plurality of error resilience levels includes a first error 
resilience level indicating a default error resilience level of the 
streaming server. 

(Underlining added). On page 5 of the Final Office Action, the Examiner also states: 

Nevertheless, Park discloses "the server 10 provides or 
informs of at least two types of coding formats and the 
terminal 20 recognizes that the corresponding contents can be 
coded in at least two coding formats. At operation S105, the 
server 10 packetizes and transmits the bit streams in a general 
coding format to the terminal 20" {Park [0042-0043]) and "the 
server 40 packetizes and transmits the bit streams in the 
general coding format to the terminal 50" (Park [0053]). 

Therefore, it would have been obvious to a person having 
ordinary skill in the art at the time the invention was made to 
have a default error resilience level of the streaming server 
because "the packetizing unit 13 packetizes the bit streams in 
a predetermined coding format" (Park r00391) . 

(Underlining added). 
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Appellants respectfully disagree and submit that the Examiner has 
mischaracterized Park and fails to properly apply the plain meaning of the claim language. 
The fact that Park discloses two different coding formats, that the format is predetermined, 
and that one of the formats is referenced as a general coding format does not teach a 
default coding format. Based on the plain meaning, a default value indicates an automatic 
assignment of a value to a parameter unless the value is changed to another value based 
on some other determination, action, etc. Park fails to provide any disclosure, teaching, 
or suggestion that a general coding format is in any way related to a "default error 
resilience level." The rejection cannot be maintained without Park showing a "default error 
resilience level." 

2. Park uses coding formats that change depending on the network state, not "a 
default error resilience level of the streaming server," as claimed 

Park describes a "packetizing unit [that] packetizes the bit streams stored in 

the contents storing unit in a predetermined coding format , and packetizes the bit streams in 

a different coding format when a state of the network changes ." (Abstract; underlining 

added). In fact, Park repeatedly describes "a packetizing unit packetizing the bit streams 

stored in the contents storing unit in a predetermined coding format, and packetizing the bit 

streams in a different coding format when a state of the network changes." (Paras. [0012], 

[0014]). Park also states that "[m]ore specifically, when the network has an abnormal state 

in the receiving of the coding reguest, the coding format is modified into a packet resilient 

coding format to be resilient from a packet loss ." (Para. [0017]; underlining added). To 

indicate the coding format used, Park states: 

packetizing a packet to be transmitted having a descriptor 
field that describes a coding format of an inner payload , 
generating the packet according to another coding format; and 
transmitting the generated packet of another coding format to 
the one or more terminals. 
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(Para. [0020]; underlining added). Park similarly states: 

...: receiving a packet having a descriptor field indicating a 
coding format of an inner payload , wherein the received 
packet is packetized in the another coding format; and 
decoding, where the packet in the another coding format is de- 
packetized. 

(Para. [0021]; underlining added). 

Thus, Park describes a first coding format for use in a first network state and 

a second coding format for use in a second network state considered abnormal. The coding 

format used is indicated to the other device using an indicator included in a descriptor field 

of the packet. Park also states: 

According to another aspect of the present invention, there is 
provided method of transmitting a packet to provide a 
multimedia streaming service to one or more terminals 
connected through a network, including: informing the one or 
more terminals of contents information comprising coding 
formats and playback time of contents; receiving a coding 
reguest from the one or more terminals to perform a coding 
process in one of the coding formats according to a state of 
the network ; and packetizing and transmitting bit streams in 
the requested coding format to the one or more terminals. 

(Para. [0016]; underlining and bolding added). 

Thus, according to Park, the server provides coding formats to the terminal 

and the terminal may select a coding format based on the state of the network. If the 

network is in an abnormal state, the coding format selected is modified into a packet 

resilient coding format. Park fails to provide any disclosure, teaching, or suggestion 

that either format is in any way related to a default error resilience level. Instead, the 

coding format is selected based on the state of the network. Park still further states: 

[0039] The packetizing unit 13 packetizes the bit streams in a 
predetermined coding format . In the case of MPEG-4, the 
coding formats are divided into a coding format to code one 
general frame into a whole and a coding format using a data 
partitioning method . 

[0040] In the first aspect according to the present invention, 
when the server 10 is connected to the terminal 20, if the 
terminal 20 transmits a describe command to the server 10, 
the server 10 transmits contents information, such as the 
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coding formats and a playback time of the contents to the 
terminal 20. Accordingly, when a state of the network 30 is 
changed, the terminal 20 adaptively selects the coding 
format according to the state of the network 30 and 
requests the selected coding format to the server 10 . The 
packetizing unit 13 packetizes the bit steams in the coding 
format requested by the terminal 20. 



[0042] At operation S102, when the terminal 20 is connected 
to the server 10, the terminal 20 transmits the describe 
command to the server 10 to obtain the contents information. 
At operation S104, the server 10 transmits the contents 
information such as the coding formats and the playback time 
of the contents to the terminal 20. Here, the server 10 provides 
or informs of at least two types of coding formats and the 
terminal 20 recognizes that the corresponding contents 
can be coded in at least two coding formats . 

[0043] At operation S105, the server 10 packetizes and 
transmits the bit streams in a general coding format to the 
terminal 20. At operation S106, the terminal 20 decodes the 
transmitted data in a decoding format suitable for the coding 
format and monitors the state of the network 30 

[0044] At operation S108, when monitoring the abnormal state 
of the network 30, at operation S1 10, the terminal 20 reguests 
the server 10 to modify the coding format into a packet 
resilient coding format to be resilient from the packet loss . At 
operation S1 12, the server 10 modifies the coding format into 
the packet resilient coding format, packetizes the bit streams 
in the modified format, and transmits the packetized bit 
streams i.e., the multimedia streams, to the corresponding 
terminals 20. 

(Paras. [0039]-[0043]; underlining and holding added). 

Thus, the server provides coding formats so that the terminal recognizes that 
there are at least two coding formats. If the network is in an abnormal state, the coding 
format is modified into a packet resilient coding format. 



3. Park does not teach that a "general coding format" is the same as a "default" 
coding format or a "a default error resilience level" 

Park provides no indication that the general coding format is a default coding 

format. The general coding format merely refers to the "coding format to code one general 

frame into a whole." (Para. [0039]; underlining added). Thus, the general coding format 
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merely distinguishes the selected coding format from the packet resilient coding format 
which is selected if the network is in an abnormal state. In fact, if the network is initially in 
an abnormal state, the packet resilient coding format would automatically be used because, 
according to Park, the coding format is selected based on the network state as monitored by 
the terminal (see para. [0044]) or by the server (see paras. [0050] and [0053]). 

The terminal device further does not need to understand which coding format 
is a default coding format because the coding format is indicated in the packet itself. Thus, 
the system as described in Park has no need for a default coding format, which is used 
automatically if no other selection is made, because the selection is always based on the 
network state and the terminal knows which coding format is used because "the packet to 
be transmitted includes a field that indicates by which coding format ... an associated inner 
payload has been coded." (Para. [0062]). 

4. Summary 

For at least the foregoing reasons, Park fails to disclose, teach, or suggest at 
least "wherein the plurality of error resilience levels includes a first error resilience level 
indicating a default error resilience level of the streaming server and a second error 
resilience level indicating an alternative error resilience level" (underlining added) as recited 
in Claims 1,18, 20, and 24-26. Park merely indicates that "the corresponding contents can 
be coded in at least two coding formats" (para. [0042]) based on the network state. A 
rejection under 35 U.S.C. 103(a) cannot be properly maintained where the references used 
in the rejection fail to disclose all of the recited claim elements. Claims 3, 5, 6, 9-11, 17, and 
27-31 depend from one of Claims 1,18, and 20. Therefore, Applicants respectfully request 
withdrawal of the rejection of Claims 1, 3, 5-7, 9-11, 15-20, 24-28, and 30-32. 

In view of the foregoing, it is respectfully submitted that Claims 1 , 3, 5-7, 9-1 1 , 
15-20, 24-28, and 30-32 are in condition for allowance. Therefore, Appellants respectfully 
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request withdrawal of the rejection of Claims 1 , 3, 5-7, 9-11,1 5-20, 24-28, and 30-32 for at 
least this reason. 

CONCLUSION 

In view of the foregoing discussion and arguments, Appellant respectfully 
submits that Claims 1 , 3, 5-7, 9-11, 1 5-20, 24-28, and 30-32 are not properly rejected under 
35 U.S.C. § 103(a) as being unpatentable over Matsui and Park. Accordingly, Appellants 
respectfully request that the Board reverse all claim rejections and indicate that a Notice of 
Allowance respecting all pending claims should be issued. 

Respectfully submitted, 

Date May 18. 2010 

FOLEY & LARDNER LLP 
Customer Number: 23524 
Telephone: (608) 258-4292 
Facsimile: (608) 258-4258 




Attorney for Appellant 
Registration No. 44,787 
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CLAIMS APPENDIX 

1 . (Previously presented, Appealed) A method for streaming media from a 
streaming server to a streaming client via a transmission channel, wherein the method 
comprises: 

receiving a first request for media from a streaming client at a streaming server; 

sending a response to the received first request from the streaming server to the 
streaming client, the response including a plurality of error resilience levels supportable by 
the streaming server in sending the media to the streaming client, wherein the plurality of 
error resilience levels includes a first error resilience level indicating a default error resilience 
level of the streaming server and a second error resilience level indicating an alternative 
error resilience level; 

receiving a second request from the streaming client at the streaming server, the 
second request including an error resilience level selected from the plurality of error 
resilience levels; and 

sending the media from the streaming server to the streaming client based on the 
error resilience level. 

2. (Canceled) 

3. (Previously presented, Appealed) The method of claim 1 , wherein said 
plurality of error resilience levels are defined in accordance with a targeted highest data loss 
rate or a packet loss rate. 

4. (Canceled) 

5. (Previously presented, Appealed) The method of claim 1 , wherein the method 
further comprises: 

receiving from the streaming client at the streaming server, a request for a different 
error resilience level; and 

adapting, by the streaming server, the error resilience level of the media sent in 
accordance with the request. 
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6. (Previously presented, Appealed) The method of claim 5, wherein said 
request is one of the following: a request for a specific error resilience level, an error 
resilience level increase request, or an error resilience level decrease request. 

7. (Previously presented, Appealed) The method of claim 1 , wherein the 
streaming server receives from the streaming client a RTCP (RTP Control Protocol (Real- 
Time Streaming Protocol)) report, indicative of transmission channel errors, and wherein the 
streaming server decides on a different error resilience level based on the RTCP report. 

8. (Canceled) 

9. (Previously presented, Appealed) The method of claim 1 , wherein the media 
at the streaming server is associated with an error resilience value indicating a media 
content error resilience level. 

10. (Previously presented, Appealed) The method of claim 9, wherein said error 
resilience value is stored in a file format in which said media is stored. 

1 1 . (Previously presented, Appealed) The method of claim 5, wherein error 
resilience adaptation is performed by switching the streaming server from sending a first 
generated stream having the error resilience level to sending a second generated stream 
having the different error resilience level, the different error resilience level differing from the 
error resilience level. 

12. (Canceled) 

13. (Canceled) 

14. (Canceled) 

1 5. (Previously presented, Appealed) The method of claim 1 , wherein sending 
the media uses a transmission channel at least partially implemented via a mobile 
communications network. 

16. (Original, Appealed) The method of claim 1 5, wherein the streaming server 
has an IP connection (Internet Protocol) to an IP-based network which is configured to be 
coupled with the mobile communications network. 

1 7. (Previously presented, Appealed) The method of claim 1 , wherein said media 
comprises at least one of the following: a video content, an audio content, a still image, 
graphics, text and speech. 
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1 8. (Previously presented, Appealed) A client device comprising: 

receiving means for receiving streaming media sent from a streaming server 
to the client device via a transmission channel and for receiving a plurality of error resilience 
levels supportable by the streaming server in streaming the media to the client device, 
wherein the plurality of error resilience levels includes a first error resilience level indicating 
a default error resilience level of the streaming server and a second error resilience level 
indicating an alternative error resilience level; 

detection means for detecting transmission channel errors; and 

sending means for sending an error resilience selection from the received plurality of 
error resilience levels to the streaming server. 

1 9. (Original) The client device of claim 1 8, wherein the client device is a mobile 
station of a cellular network. 

20. (Previously presented, Appealed) A streaming server comprising: 

receiving means for receiving a first request for media from a streaming client and 
for receiving a second request from the streaming client, the second request including an 
error resilience level selected from a plurality of error resilience levels, wherein the plurality 
of error resilience levels includes a first error resilience level indicating a default error 
resilience level of the streaming server and a second error resilience level indicating an 
alternative error resilience level; and 

sending means for sending a response to the first request to the streaming client, 
the response including the plurality of error resilience levels supportable by the streaming 
server in sending the media to the streaming client and for sending streaming media to the 
streaming client via a transmission channel based on the error resilience level. 

21. (Canceled) 

22. (Canceled) 

23. (Canceled) 

24. (Previously presented, Appealed) A computer-readable memory including 
computer-readable program code that, upon execution by a processor, cause a device to: 

send a response to a first device requesting media, the response including a plurality 
of error resilience levels supportable when sending the media to the first device, wherein the 
plurality of error resilience levels includes a first error resilience level indicating a default 
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error resilience level of the device and a second error resilience level indicating an 
alternative error resilience level; 

process a second request received from the first device, the second request 
including an error resilience level selected from the plurality of error resilience levels; and 

send the media to the first device based on the error resilience level. 

25. (Previously presented, Appealed) A computer-readable memory including 
computer-readable program code that, upon execution by a processor, cause the processor 
to receive streamed media from a streaming server via a transmission channel, the 
program code configured to cause a device to: 

send a first request for media to a streaming server; 

receive a response from the streaming server, the response including a plurality of 
error resilience levels supportable by the streaming server when sending the media, wherein 
the plurality of error resilience levels includes a first error resilience level indicating a default 
error resilience level of the streaming server and a second error resilience level indicating an 
alternative error resilience level; 

send a second request to the streaming server, the second request including an 
error resilience level selected from the plurality of error resilience levels; and 

receive the media from the streaming server based on the error resilience level. 

26. (Previously presented, Appealed) A method for receiving streamed media 
from a streaming server via a transmission channel, the method comprising: 

sending a first request for media from a streaming client to a streaming server; 

receiving a response from the streaming server at the streaming client, the response 
including a plurality of error resilience levels supportable by the streaming server when 
sending the media, wherein the plurality of error resilience levels includes a first error 
resilience level indicating a default error resilience level of the streaming server and a 
second error resilience level indicating an alternative error resilience level; 

sending a second request from the streaming client to the streaming server, the 
second request including an error resilience level selected from the plurality of error 
resilience levels; and 
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receiving the media from the streaming server at the streaming client based on the 
error resilience level. 

27. (Previously presented, Appealed) The method of claim 1 , wherein the error 
resilience level is an integer value. 

28. (Previously presented, Appealed) The method of claim 1 , further comprising 
identifying a media content error resilience level from the media wherein the plurality of error 
resilience levels includes the identified media content error resilience level. 

29. (Canceled) 

30. (Previously presented, Appealed) The method of claim 1 , further comprising 
selecting a media stream to send the media from a plurality of media streams based on the 
error resilience level. 

31 . (Previously presented, Appealed) The method of claim 1 , further comprising, 
after sending the media from the streaming server to the streaming client, receiving a third 
request from the streaming client at the streaming server, the third request including a new 
error resilience level selected based on an error rate. 

32. (Previously presented, Appealed) The method of claim 1 , further comprising, 
receiving a third request from the streaming client at the streaming server, the third request 
including a request to identify a current error resilience level. 
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